Updated for WorldEdit 6.0 #542
Conversation
|
Working in Test & Implemented to the WorldEdit specs for a block logger (to the best of my knowledge) |
| @@ -57,7 +58,7 @@ public void onEntityExplode(EntityExplodeEvent event) { | |||
| name = "Creeper"; | |||
| } else if (source instanceof Fireball) { | |||
| Fireball fireball = (Fireball) source; | |||
| Entity shooter = fireball.getShooter(); | |||
| ProjectileSource shooter = fireball.getShooter(); | |||
|
I would not necessarily use this yet, as the API in WE may change a bit in the next week. |
|
@DarkArc Compiled your branch again, get this error when typing /lb redo player (player) area (#) time (time) |
|
@mibby That shouldn't happen, it compiles fine for me, I also didn't touch the commands system, so it's extra strange... |
|
Odd. It compiled fine for me too. Just using the command in-game, it errors. I'll recompile with your newer commit and test again later today. |
|
@mibby Still getting this error? |
| return; | ||
| } | ||
|
|
||
| Location location = new Location(((BukkitWorld) event.getWorld()).getWorld(), pt.getBlockX(), pt.getBlockY(), pt.getBlockZ()); |
There was a problem hiding this comment.
event.getWorld() could return ForgeWorld if people install WorldEdit in both Forge and Bukkit at the same time (via MCPC-Plus), or SomeOtherWorld if people made a custom world.
You could also handle this outside onBlockChange(...).
There was a problem hiding this comment.
It wouldn't matter that the world was a forge world and a bukkit world at the same time would it, just so long as it has the bukkit features we need?
EDIT: Oh... I just realized what you meant, it would return a ForgeWorld despite supporting bukkit features.
@sk89q is that week over now? :P |
|
The code base for 6.0 is still not complete and is still subject to change afaik. It's best not to merge this till WE 6 is actually released, I'll keep this updated as any breaking changes are made. |
|
does this mean WE has broken LBs ability to log WE or LB has made a recent change that renders it unable to log WE |
|
WE has made breaking changes and LB didn't update since. However this PR seems to be working. |
|
@jomo can you provide link to where i can get the working build if poss? |
|
No idea if Dark has a build server, I just used maven and built it myself. |
|
@jomo ah well i havent learned that much ill just wait lol |
…is. Fixes #538, fixes #568 This creates a new column in the lb-players table called UUID. If this is in the form of a UUID, it's assumed to be a player. If not, it's assumed to be a server entity (zombie, sheep, or WaterFlow, LavaFlow etc.). LogBlock will set the UUID of entities to "log_" plus their name (i.e. log_zombie or log_sheep) To assist this is a new class Actor, which wraps a name/UUID pair, with constructors that will generate one from server entities, or SQL results. Every listener and every class in Consumer needed to be updated to deal with this As of yet, only the playername is displayed in results (although the queries do return UUID data). Similarly, you can only query by name (the database stores the last name they have logged in as). In addition, the WorldEdit hook has been disabled (is not compiled) since LB needs to be updated to use their new API, and the LB code hook has to extract UUID information for insertion. The UUID importer assumes any player with an onlinetime of 0 is a server-generated source, and set the UUID as above (log_sheep etc.). For everything else, it sends 100 names at a time to Mojang's name->UUID service, and records them if available. If no result is found, it records their UUID as noimport_theirname. As this is more likely than other updates to be interrupted mid-way, the importer is tolerant of e.g. the column already being added, and will resume where it left off.
|
@DarkArc I've updated this PR for the new UUID support*. Given you comment here would you prefer I opened a new PR to continue this so you don't get the hassle? My branch is at https://github.com/frymaster/LogBlock/tree/DarkArc-worldedit-6.0.0 * Which means "it builds" - I'm at work atm so can't test until I get home |
|
Nah, I've got some time. I don't have an environment to test anything anymore, but I can comment. My only suggestion is the conversion could be changed slightly: You should be able to make use of the Identifiable interface, and directly access the UUID, and not have to worry about doing an Entity look up: Also, I'm not sure what @sk89q decided, but before I left, there was some discussion that the following should be used for the world look up: However, this is still a package local class, and thereby method. If it becomes the case that this is accessible, the below implementation of world look up could be used, with the contents of the try block being replaced by the BukkitAdapter's world adapt method: The concern with just using the name look up was that on multiple API WorldEdit platforms (where more than one API is being used at once), there might be inconsistencies in the look up. Edit: Corrected some grammar. |
|
That method is still inaccessible, so I had to move the logic into our code. If we can get a BukkitWorld object to spit out a Bukkit World, we will. Otherwise, we'll try looking for one with the same name. Is that what you had in mind? |
|
That seems fine, might be better if you refactored the world lookup logic into it's own function though, so that try catch isn't so messy. Basically, giving the class it's own adapt method. |
Testing is pending.